CloudWatch AlarmのAuto Recoveryに触れる

CloudWatch Alarmで設定できるEC2のAuto Recoveryついて調べました。

#AWS

#Amazon CloudWatch

#CloudWatch Alarm

大村保貴

2020.07.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、網走の大村です。
CloudWatch Alarmで設定できるEC2のAuto Recoveryついて調べました。

発端

EC2の標準メトリクスだけで何かアラート設定したいけどオススメある？と社内Slackで軽く聞いてみたところ、 Auto Recovery を設定する機会が多いかも。よかれと思ってアラート設定してもアラート大量に飛んできても迷惑だよね。との声。お客様から監視についての要望がないときや、とくに運用面まで深く考えている時間がない、運用担当者はいないから兼務で頑張ります!というお客様のときに役に立つアラートは何かと考えたところ、単体のEC２インスタンスなら Auto Recovery はあって損はないだろうという押し付けがましい結論に至り調べました。

なにが嬉しいの？

Auto Recoveryを設定しておくとAWSの基盤の問題でEC2インスタンスが落ちたとき自動的にインスタンスの停止開始してくれる。なにか障害が起きたら担当者が手動で停止開始しますが一次対応くらいの運用なら自動的にやってくれたら助かる、とくに夜間。

Auto Recoveryの設定方法

設定はこちらを参考に、せっかくなので簡単に說明します。
【新機能】EC2 Cloudwatchの新機能「Auto Recovery」を使ってみた | Developers.IO

Auto Recoveryとは

EC2インスタンスの システムステータスチェック が失敗したときに、EC2のインスタンスを自動的に停止/開始を実行してくれるCloudWatch Alarmの機能です。

システムステータスとは

EC2インスタンスが実行されているAWSの基板側の状態（死活監視）です。

インスタンスが実行されているAWSシステムを監視します。これらのチェックでは、修復には AWS の関与が必要なインスタンスの根本的な問題が検出されます。システムステータスチェックが失敗した場合、AWS が問題を解決するのを待つか、自分で解決できるかを選択できます。Amazon EBS でバックアップされたインスタンスの場合は、インスタンスを自分で停止および起動することができます。通常、インスタンスは新しいホストに移行されます。インスタンスストアによってサポートされているインスタンスの場合、インスタンスを終了して置き換えることができます。

システムステータスチェックの失敗の原因の例

ネットワーク接続の喪失
システム電源の喪失
物理ホストのソフトウェアの問題
ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

私の勘違い

Auto Recoveryの機能は知っていたものの前職では使っていませんでした。職場の環境にもよると思いますが...手動でEC2インスタンスを停止しても勝手に起動してくるんじゃないの？それだと設定入っていることを知らない人と後々面倒毎になりそうだからいいやと勝手に思っていました。調べてみるとどうやらそんなことはないとわかり、とは言え不安なので確認してみました。

検証してみた

意図的にシステムチェックの失敗は引き起こせないのでAuto Recoveryのテストができないとググるとでてくるが、どういうことかいまいち理解できないので試してみました。

CloudWatch Alarmを設定

ステータスチェックに対してこのインスタンスを復旧を選択して、Auto Recoveryの設定をしました。

EC2インスタンスを手動停止した場合

EC2インスタンスをマネージドコンソールから手動で停止をクリックした。

結果

アクションが失敗しており停止/開始が実行されないため、EC2インスタンスは停止したまま。なにか設定間違ってたのかな、IAMロールでEC2に対する権限必要だったのかなと自分の設定を疑う。

エラーメッセージを見ても理由はわからない。

{
  "actionState": "Failed",
  "stateUpdateTimestamp": 1594792768753,
  "notificationResource": "arn:aws:automate:ap-northeast-1:ec2:recover",
  "publishedMessage": null,
  "error": null
}